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(54) Semaphore for a computer system 

(57) A computer system is described in which 
access to a shared resource is controlled by a sema- 
phore. The semaphore comprises a lock value and a 
key value. When a process wishes to access the shared 
resource, it calls a reserve function which increments 
the lock value and stores the unchanged value of the 
lock value in a local variable. The reserve function then 
performs a loop in which it repeatedly compares the key 
value with the local variable until they equal. When the 
process has finished with the shared resource, it calls a 
release function which increments the key value. This 
guarantees to allocate the semaphore to processes in 
the order in which the processes requested it (i.e. in 
chronological order), in a cheap and effective manner. 
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Description 

Background to the Invention 

[0001] This invention relates to semaphores for com- s 
puter systems. 

[0002] A semaphore is a mechanism for controlling 
access to a shared resource by a number of concurrent 
processes. The shared resource may, for example, be 
an area of shared memory. The concurrent processes 10 
may run on a single processor, or on different proces- 
sors. 

[0003] In one known form of semaphore, referred to as 
a spinlock semaphore, each shared resource has a 
semaphore bit associated with it. Whenever a process is 
wishes to access a shared resource, it tests the sema- 
phore bit associated with the resource. If the sema- 
phore bit is set, the process "spins" in a tight loop, in 
which it repeatedly tests the semaphore value. When 
the process finds that the semaphore bit is reset, it sets 20 
the semaphore bit and proceeds to access the shared 
resource. The testing and setting of the semaphore bit 
must be performed as a single atomic (i.e. indivisible) 
operation. When the process has finished accessing the 
shared resource, it resets the semaphore bit. 25 
[0004] A problem with this conventional spinlock sem- 
aphore, however, is that it cannot guarantee to allocate 
the semaphore to the processes in the order in which 
the processes requested it. In particular, it is possible for 
two processes to continually swap a resource between 30 
them, thereby blocking a third process. The object of the 
present invention is to provide an improved spinlock 
semaphore that is guaranteed to allocate the sema- 
phore in the order in which the processes requested it. 

35 

Summary of the Invention 

[0005] According to the invention, a method of control- 
ling access by a plurality of processes to a plurality of 
shared resources in a computer system comprises: 40 

(a) providing each of the shared resources with a 
first semaphore value and a second semaphore 
value; 

(b) when a process requires to access a shared 45 
resource, storing a reservation number as a local 
variable for the process, the reservation number 
being derived from the first semaphore value of the 
resource, updating the first semaphore value of the 
resource in a predetermined manner, performing a so 
loop which repeatedly compares the reservation 
number stored for the process with the second 
semaphore value of the resource, and permitting 

the process to access the resource when the reser- 
vation number stored for the process is in a prede- 55 
termined relationship with the second semaphore 
value of the resource; and 

(c) when a process has finished accessing a shared 



resource, updating the second semaphore value of 
the resource in a predetermined manner. 

Brief Description of the Drawings 
[0006] 

Figure 1 is a schematic diagram showing a compu- 
ter system embodying the invention. 

Figure 2 is a flow chart showing part of a client 
process. 

Figure 3 is a flow chart of a Reserve_semaphore 
function. 

Figure 4 is a flow chart of a Release_semaphore 
function. 

Description of an Embodiment of the Invention 

[0007] One semaphore mechanism in accordance 
with the invention will now be described by way of exam- 
ple with reference to the accompanying drawings. 
[0008] Figure 1 shows a computer system 10, which 
runs a number of client processes 11. The system may 
comprise a single processing unit with a multi-threading 
operating system allowing a number of processes to run 
concurrently. Alternatively, the system may be a multi- 
processor system, in which different processes can run 
simultaneously on different processors. 
[0009] The client processes 1 1 share a number of 
resources 12, such as memory. Each resource has a 
semaphore 13 associated with it. The semaphore com- 
prises a lock value 1 4 and a key value 1 5. The lock and 
key values are shared variables, and in this embodiment 
are initially set to the same value. 
[0010] Two functions are provided for managing the 
semaphores: a Reserve_semaphore() function 16 and 
a Release_semaphoreO function 17. These functions 
can be called by the client processes. 
[0011] Figure 2 shows part of one of the client proc- 
esses which makes use of the semaphore. 
[0012] (Step 21) When the client process wishes to 
access a shared resource, it calls the 
Reserve_semaphoreO function. The call contains a 
parameter, specifying the identity of the semaphore 
associated with the resource in question. 
[0013] (Step 22) When this call returns, the client 
process accesses the shared resource. 
[0014] (Step 23) The client process then calls the 
Release_semaphoreO function. 
[0015] Figure 3 shows the Reserve_semaphore() 
function. 

[0016] (Step 31) The function increments the lock 
value of the semaphore, and sets a local variable 
origjock equal to the unincremented value of the lock. 
This must be done as a single indivisible action. For 
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example, this step may be performed by the following 
Intel code: 

mov eax, 1 

xadd lock, eax ; this is the indivisible action 
mov orig_lock,eax 

[0017] It should be noted that there is a separate 
origjock per client, whereas all clients share the same 
lock and key values. 

[0018] (Step 32) The function then compares the key 
value of semaphore with the origjock value. If they are 
equal, the function returns; otherwise it repeats Step 32. 
Thus, the function performs a loop in which it repeatedly 
tests the key value of the semaphore, until the key value 
becomes equal to the origjock value. 
[0019] Figure 4 shows the Release_semaphoreO 
function. 

[0020] (Step 41) The function increments the key 
value associated with the semaphore, and then returns. 
(Instead of incrementing the key, this step may set key = 
origjock + 1 , which in this embodiment gives the same 
result). 

[0021 ] It is not strictly necessary for the incrementing 
of the key value to be performed as an indivisible action, 
since the only client allowed to update the key value is 
the one currently holding the semaphore. 
[0022] In summary, it can be seen that the system pro- 
vides a spinlock semaphore having two components: a 
lock value and a key value. When a process reserves a 
semaphore, the lock value is incremented and its unin- 
cremented value is saved as a local variable origjock. 
If origjock is equal to the key value, the process can 
immediately access the shared resource. If on the other 
hand origjock is not equal to the key value (because 
one or more processes have previously reserved the 
semaphore, and have not yet released it), a spin loop is 
entered. Eventually, the previous processes will release 
the semaphore, by incrementing the key value. When 
the key value becomes equal to origjock, the process 
is allowed to proceed to access the shared resource. 
[0023] In other words, when a process wishes to 
access a particular resource, it is allocated a reserva- 
tion number (origjock), derived from the lock value of 
the resource. The process then waits until the key value 
of the resource is in a predetermined relationship with 
(in this embodiment, is equal to) the reservation number 
of the process, before accessing the resource. 
[0024] The semaphore guarantees to allocate the 
semaphore to processes in the order in which the proc- 
esses requested it (i.e. in chronological order). It is also 
very cheap (in terms of processing time and memory 
requirements) and effective. 

[0025] It will be appreciated that the lock and key val- 
ues will eventually reach a maximum value, and will roll- 
over to zero. 

[0026] This maximum value must be chosen to be 
greater than the maximum number of 



Reserve_semaphore requests that may be pending at 
any given time. 

Some possible modifications 

5 

[0027] It will be appreciated that many modifications 
may be made to the system described above without 
departing from the scope of the present invention. 
[0028] Different functions may be used to update the 

10 lock and key. For example, instead of incrementing the 
lock and key, they may be decremented or rotated. 
[0029] Furthermore, instead of initialising the lock and 
key to the same value, they may initially have different 
values. In this case, instead of comparing the origjock 

is and key for equality, the comparison checks whether the 
difference between origjock and key is the same as the 
difference between the lock and key at start of day. 

Claims 

20 

1. A method of controlling access by a plurality of 
processes to a plurality of shared resources in a 
computer system, the method comprising: 

25 (a) providing each of the shared resources with 

a first semaphore value and a second sema- 
phore value; 

(b) when a process requires to access a shared 
resource, storing a reservation number as a 

30 local variable for the process, the reservation 

number being derived from the first semaphore 
value of the resource, updating the first sema- 
phore value of the resource in a predetermined 
manner, performing a loop which repeatedly 

35 compares the reservation number stored for 

the process with the second semaphore value 
of the resource, and permitting the process to 
access the resource when the reservation 
number stored for the process is in a predeter- 

40 mined relationship with the second semaphore 

value of the resource; 
and 

(c) when a process has finished accessing a 
shared resource, updating the second sema- 

45 phore value of the resource in a predetermined 

manner. 

2. A method according to Claim 1 wherein updating 
the first semaphore value and storing the reserva- 

50 tion number as a local variable are performed as a 
single indivisible action. 

3. A method according to Claim 1 or 2, wherein updat- 
ing the first semaphore value comprises increment- 

55 ing the first semaphore value, and updating the 
second semaphore value comprises incrementing 
the second semaphore value 
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4. A method according to any preceding claim 
wherein the first and second semaphore key values 
are initially set equal, and wherein the loop repeat- 
edly compares the reservation number with the 
second semaphore value until they are equal. 5 

5. A computer system comprising: 

(a) a plurality of processes; 

(b) a plurality of shared resources, each having 10 
a first semaphore value and a second sema- 
phore value; 

(c) a reserve function, callable by a process 
when the process requires to access a shared 
resource, the reserve function comprising 15 
means for storing a reservation number as a 
local variable for the process, the reservation 
number being derived from the first semaphore 
value of the resource, means for updating the 
first semaphore value of the resource in a pre- 20 
determined manner, means for performing a 
loop which repeatedly compares the reserva- 
tion number stored for the process with the 
second semaphore value of the resource, and 
means for permitting the process to access the 25 
resource when the reservation number stored 

for the process is in a predetermined relation- 
ship with the second semaphore value of the 
resource; 

and 30 

(d) a release function callable by a process 
when the process has finished accessing a 
shared resource, the release function compris- 
ing means for updating the second semaphore 
value of the resource in a predetermined man- 35 
ner. 

6. A computer system according to Claim 5 compris- 
ing means for updating the first semaphore value 
and storing the reservation number as a local varia- 40 
ble, as a single indivisible action. 

7. A computer system according to Claim 5 or 6, 
wherein the means for updating the first semaphore 
value comprises means for incrementing the first 45 
semaphore value, and the means for updating the 
second semaphore value comprises means for 
incrementing the second semaphore value 

8. A computer system according to any one of Claims so 
5 to 7 wherein the first and second semaphore key 
values are initially set equal, and wherein the 
means for performing a loop repeatedly compares 
the reservation number with the second semaphore 
value until they are equal. 55 
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